1. Field of the Invention
This invention relates generally to electronic commerce systems and more particularly to using encryption to protect data in the system.
2. Background of the Invention
With the advent of electronic forms of communication, including telegraph, telephone, radio, television, and more recently digital networks, it has become possible to conduct commerce electronically using digital computer systems. Electronically encoded funds are different than physical currency in that it is a trivial matter to duplicate electronic representations of funds. The most difficult task faced in conducting computerized commerce is to detect the illegal re-use of electronic funds, e.g., double spending.
Known electronic fund transfer systems generally require a xe2x80x9ctrustedxe2x80x9d third party between the vendor and consumer to authenticate the validity of the electronic funds. The requirement of a third party adds expense to every transaction because of the cost of extra communications and encryption. In addition, current electronic fund transfer networks, e.g., Western Union and Federal Reserve banks, typically require physically secure communications media which is immune to xe2x80x9ceavesdropping.xe2x80x9d Such secure networks are generally not available to consumers at large.
Alternative methods of electronic fund transactions involve establishing a long-term relationship between the vendor and consumer, either through a subscription service or by billing accounts as are provided by credit card organizations. These methods are efficient at handling transaction requests, assuming a reasonable authentication scheme. However, these methods require a prior effort to establish an xe2x80x9caccountxe2x80x9d or other evidence of credit worthiness. For a large number of consumers, e.g. all potential users of a large network of computers like the Internet, setting up accounts and maintaining credit information adds expense to the vendors, and inconvenience and impediments to the consumers.
The recent growth of public access communications networks, such as the Internet, has accelerated the need for a low-cost computerized electronic commerce system. In addition, in the information marketplace there is a particular need to economically support transactions that are for amounts as small as a hundredth of a cent.
U.S. Pat. No. 5,802,497 (the ""497 patent) describes a lightweight and secure protocol for electronic commerce over the Internet. The protocol is designed to support purchases costing less than a cent. The system is based on decentralized validation of electronic cash at a vendor""s server, without any additional communication, expensive encryption, or off-line processing.
Two innovations in the ""497 patent are its use of brokers and scrip. Brokers take care of account management, billing, connection maintenance, and establishing accounts with vendors. Scrip is digital cash that is valid for only a specific vendor. The vendor locally validates the scrip to prevent customer fraud, such as double spending.
Every time a user visits a new vendor, the user must get scrip for that vendor from a broker. Scrip is held and manipulated by the user using an application called a xe2x80x9cwallet.xe2x80x9d The wallet includes scrip with each request to purchase content and gets back change from the vendor with the returned content.
For each piece of scrip in the wallet, the wallet holds a secret (the xe2x80x9cCustomer Secretxe2x80x9d or xe2x80x9cCSxe2x80x9d). The wallet uses the CS to prove to the vendor that the consumer is authorized to spend the scrip. The wallet must protect the CS from third parties. Otherwise, an unauthorized third party with access to the wallet could spend the scrip.
Accordingly, there is need to encrypt the scrip""s CS stored by the wallet. The encryption should be relatively robust (i.e., difficult to decipher), but need not be excessive given the low value of the scrip. Moreover, the encryption should not add excessive overhead to the electronic commerce system nor make the system harder to use by the consumer.
The above needs are met by a method and system of conducting computerized commerce on a number of computer systems connected by a computer network. The system includes a broker computer system having a database of broker scrips, each broker scrip representing a form of electronic currency. The system also includes a vendor computer system having a database containing products which may be exchanged for the broker scrips, the vendor computer system capable of providing vendor scrips. In addition, the system includes a consumer computer system having a user interface whereby a consumer may initiate transactions in the consumer computer system to obtain one or more of the products contained in the database of the vendor computer system.
Each piece of scrip has a value, which may range from a few dollars to a few hundredths of a cent. In addition, each piece of scrip has a Scrip ID which uniquely identifies the scrip and a Customer ID which identifies the consumer entitled to spend the scrip. The scrip also has a stamp that is used to verify that the scrip has not been altered.
When issuing scrip, the broker generates a customer secret (CS) from the Customer ID and sends the CS and scrip to the consumer. If the CS is the first CS received by the consumer, the broker uses a secure channel to transmit the CS. Otherwise, the broker uses the old CS to communicate the new CS to the consumer without actually transmitting the new CS in the clear. The consumer holds the scrip and its associated CS in a database called a xe2x80x9cwallet.xe2x80x9d
When the consumer desires to purchase product from the vendor, the consumer sends the vendor a request, the scrip, and a hash of the scrip, request, and CS. Preferably, the hashing algorithm is MD5, although other hashes can be used instead. The vendor verifies that the consumer has not tampered with the scrip and verifies that the consumer possesses the correct CS. If the consumer has transmitted valid scrip and proves knowledge of the correct CS, the vendor provides the requested product to the consumer.
To keep third parties from accessing the wallet and spending the consumer""s scrip, the customer secrets in the wallet are encrypted using a consumer-provided pass phrase. To strengthen the pass phrase, the wallet preferably concatenates the consumer-provided phrase with a first nonce (a random, guaranteed unique string) and a short random number, thereby forming an internal pass phrase. The length of the short random number, i.e. the number of bits in the number, is determined by the processing power of the consumer""s computer system. The first nonce is stored in a header of the wallet file.
The wallet hashes the internal pass phrase with a second nonce to generate a checksum. Then, the wallet stores a triple having the checksum, the second nonce, and the length of the short random number. In addition, the wallet encrypts the CS associated with each scrip by hashing a unique nonce with the internal pass phrase and then XORing the result with the CS. For each scrip, the wallet stores a triple holding the scrip, the nonce used to encrypt the CS, and the encrypted CS. Preferably, all of the nonces and the short random number are changed, and the checksum and hashes are regenerated, each time the wallet is written.
To unlock the wallet and spend the scrip, the consumer provides a pass phrase. The wallet concatenates the provided pass phrase with the first nonce. In addition, the wallet appends a random number having the length read from the triple holding the checksum to the provided pass phrase/first nonce string. Then, the wallet calculates the hash of the second nonce and the provided pass phrase, the first nonce, and the random number, and determines whether the result matches the checksum. The hash is performed with all possible values for the random number until either a match is found or all possible values have been tried. If a match is found, the wallet treats the concatenation of the consumer""s pass phrase, the nonce, and the random number as a single internal pass phrase. Then, the wallet decrypts the CS in the wallet by hashing the nonce for the scrip with the internal pass phrase and XORing the result with the encrypted CS. If no match is found, then the consumer, or some unauthorized party, has given an invalid pass phrase. Thus, the encrypted CS cannot be decrypted, and the scrip cannot be spent, without the proper consumer-provided pass phrase.